System and method for securely connecting network devices

ABSTRACT

A platform, apparatus and method for Internet of Things Implementations. For example, one embodiment of a system comprises: an Internet of Things (IoT) hub comprising a network interface to couple the IoT hub to an IoT service over a wide area network (WAN), and programming logic to program an identification device with one or more encryption keys usable to establish encrypted communication with an IoT device; and at least one IoT device interfacing with the identification device following programming of the identification device by the IoT hub; wherein once the identification device is programmed and interfaced with the IoT device, the IoT device uses the one or more keys to establish a secure communication channel with the IoT hub and/or the IoT service.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 14/575,463, filed Dec. 18, 2014, all of which is herebyincorporated by reference.

BACKGROUND Field of the Invention

This invention relates generally to the field of computer systems. Moreparticularly, the invention relates to Internet of a system and methodfor securely connecting network devices.

Description of the Related Art

The “Internet of Things” refers to the interconnection ofuniquely-identifiable embedded devices within the Internetinfrastructure. Ultimately, IoT is expected to result in new,wide-ranging types of applications in which virtually any type ofphysical thing may provide information about itself or its surroundingsand/or may be controlled remotely via client devices over the Internet.

IoT development and adoption has been slow due to issues related toconnectivity, power, and a lack of standardization. For example, oneobstacle to IoT development and adoption is that no standard platformexists to allow developers to design and offer new IoT devices andservices. In order enter into the IoT market, a developer must designthe entire IoT platform from the ground up, including the networkprotocols and infrastructure, hardware, software and services requiredto support the desired IoT implementation. As a result, each provider ofIoT devices uses proprietary techniques for designing and connecting theIoT devices, making the adoption of multiple types of IoT devicesburdensome for end users. Another obstacle to IoT adoption is thedifficulty associated with connecting and powering IoT devices.Connecting appliances such as refrigerators, garage door openers,environmental sensors, home security sensors/controllers, etc, forexample, requires an electrical source to power each connected IoTdevice, and such an electrical source is often not conveniently located.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained from thefollowing detailed description in conjunction with the followingdrawings, in which:

FIGS. 1A-B illustrates different embodiments of an IoT systemarchitecture;

FIG. 2 illustrates an IoT device in accordance with one embodiment ofthe invention;

FIG. 3 illustrates an IoT hub in accordance with one embodiment of theinvention;

FIG. 4 illustrates a high level view of one embodiment of a securityarchitecture;

FIG. 5 illustrates one embodiment of an architecture in which asubscriber identity module (SIM) is used to store keys on IoT devices;

FIG. 6A illustrates one embodiment in which IoT devices are registeredusing barcodes or QR codes;

FIG. 6B illustrates one embodiment in which pairing is performed usingbarcodes or QR codes;

FIG. 7 illustrates one embodiment of a method for programming a SIMusing an IoT hub;

FIG. 8 illustrates one embodiment of a method for registering an IoTdevice with an IoT hub and IoT service; and

FIG. 9 illustrates one embodiment of a method for encrypting data to betransmitted to an IoT device.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the embodiments of the invention described below. Itwill be apparent, however, to one skilled in the art that theembodiments of the invention may be practiced without some of thesespecific details. In other instances, well-known structures and devicesare shown in block diagram form to avoid obscuring the underlyingprinciples of the embodiments of the invention.

One embodiment of the invention comprises an Internet of Things (IoT)platform which may be utilized by developers to design and build new IoTdevices and applications. In particular, one embodiment includes a basehardware/software platform for IoT devices including a predefinednetworking protocol stack and an IoT hub through which the IoT devicesare coupled to the Internet. In addition, one embodiment includes an IoTservice through which the IoT hubs and connected IoT devices may beaccessed and managed as described below. In addition, one embodiment ofthe IoT platform includes an IoT app or Web application (e.g., executedon a client device) to access and configured the IoT service, hub andconnected devices. Existing online retailers and other Website operatorsmay leverage the IoT platform described herein to readily provide uniqueIoT functionality to existing user bases.

FIG. 1A illustrates an overview of an architectural platform on whichembodiments of the invention may be implemented. In particular, theillustrated embodiment includes a plurality of IoT devices 101-105communicatively coupled over local communication channels 130 to acentral IoT hub 110 which is itself communicatively coupled to an IoTservice 120 over the Internet 220. Each of the IoT devices 101-105 mayinitially be paired to the IoT hub 110 (e.g., using the pairingtechniques described below) in order to enable each of the localcommunication channels 130. In one embodiment, the IoT service 120includes an end user database 122 for maintaining user accountinformation and data collected from each user's IoT devices. Forexample, if the IoT devices include sensors (e.g., temperature sensors,accelerometers, heat sensors, motion detectore, etc), the database 122may be continually updated to store the data collected by the IoTdevices 101-105. The data stored in the database 122 may then be madeaccessible to the end user via the IoT app or browser installed on theuser's device 135 (or via a desktop or other client computer system) andto web clients (e.g., such as websites 130 subscribing to the IoTservice 120).

The IoT devices 101-105 may be equipped with various types of sensors tocollect information about themselves and their surroundings and providethe collected information to the IoT service 120, user devices 135and/or external Websites 130 via the IoT hub 110. Some of the IoTdevices 101-105 may perform a specified function in response to controlcommands sent through the IoT hub 110. Various specific examples ofinformation collected by the IoT devices 101-105 and control commandsare provided below. In one embodiment described below, the IoT device101 is a user input device designed to record user selections and sendthe user selections to the IoT service 120 and/or Website.

In one embodiment, the IoT hub 110 includes a cellular radio toestablish a connection to the Internet 220 via a cellular service 115such as a 4G (e.g., Mobile WiMAX, LTE) or 5G cellular data service.Alternatively, or in addition, the IoT hub 110 may include a WiFi radioto establish a WiFi connection through a WiFi access point or router 116which couples the IoT hub 110 to the Internet (e.g., via an InternetService Provider providing Internet service to the end user). Of course,it should be noted that the underlying principles of the invention arenot limited to any particular type of communication channel or protocol.

In one embodiment, the IoT devices 101-105 are ultra low-power devicescapable of operating for extended periods of time on battery power(e.g., years). To conserve power, the local communication channels 130may be implemented using a low-power wireless communication technologysuch as Bluetooth Low Energy (LE). In this embodiment, each of the IoTdevices 101-105 and the IoT hub 110 are equipped with Bluetooth LEradios and protocol stacks.

As mentioned, in one embodiment, the IoT platform includes an IoT app orWeb application executed on user devices 135 to allow users to accessand configure the connected IoT devices 101-105, IoT hub 110, and/or IoTservice 120. In one embodiment, the app or web application may bedesigned by the operator of a Website 130 to provide IoT functionalityto its user base. As illustrated, the Website may maintain a userdatabase 131 containing account records related to each user.

FIG. 1B illustrates additional connection options for a plurality of IoThubs 110-111, 190 In this embodiment a single user may have multiplehubs 110-111 installed onsite at a single user premises 180 (e.g., theuser's home or business). This may be done, for example, to extend thewireless range needed to connect all of the IoT devices 101-105. Asindicated, if a user has multiple hubs 110, 111 they may be connectedvia a local communication channel (e.g., Wifi, Ethernet, Power LineNetworking, etc). In one embodiment, each of the hubs 110-111 mayestablish a direct connection to the IoT service 120 through a cellular115 or WiFi 116 connection (not explicitly shown in FIG. 1B).Alternatively, or in addition, one of the IoT hubs such as IoT hub 110may act as a “master” hub which provides connectivity and/or localservices to all of the other IoT hubs on the user premises 180, such asIoT hub 111 (as indicated by the dotted line connecting IoT hub 110 andIoT hub 111). For example, the master IoT hub 110 may be the only IoThub to establish a direct connection to the IoT service 120. In oneembodiment, only the “master” IoT hub 110 is equipped with a cellularcommunication interface to establish the connection to the IoT service120. As such, all communication between the IoT service 120 and theother IoT hubs 111 will flow through the master IoT hub 110. In thisrole, the master IoT hub 110 may be provided with additional programcode to perform filtering operations on the data exchanged between theother IoT hubs 111 and IoT service 120 (e.g., servicing some datarequests locally when possible).

Regardless of how the IoT hubs 110-111 are connected, in one embodiment,the IoT service 120 will logically associate the hubs with the user andcombine all of the attached IoT devices 101-105 under a singlecomprehensive user interface, accessible via a user device with theinstalled app 135 (and/or a browser-based interface).

In this embodiment, the master IoT hub 110 and one or more slave IoThubs 111 may connect over a local network which may be a WiFi network116, an Ethernet network, and/or a using power-line communications (PLC)networking (e.g., where all or portions of the network are run throughthe user's power lines). In addition, to the IoT hubs 110-111, each ofthe IoT devices 101-105 may be interconnected with the IoT hubs 110-111using any type of local network channel such as WiFi, Ethernet, PLC, orBluetooth LE, to name a few.

FIG. 1B also shows an IoT hub 190 installed at a second user premises181. A virtually unlimited number of such IoT hubs 190 may be installedand configured to collect data from IoT devices 191-192 at user premisesaround the world. In one embodiment, the two user premises 180-181 maybe configured for the same user. For example, one user premises 180 maybe the user's primary home and the other user premises 181 may be theuser's vacation home. In such a case, the IoT service 120 will logicallyassociate the IoT hubs 110-111, 190 with the user and combine all of theattached IoT devices 101-105, 191-192 under a single comprehensive userinterface, accessible via a user device with the installed app 135(and/or a browser-based interface).

As illustrated in FIG. 2, an exemplary embodiment of an IoT device 101includes a memory 210 for storing program code and data 201-203 and alow power microcontroller 200 for executing the program code andprocessing the data. The memory 210 may be a volatile memory such asdynamic random access memory (DRAM) or may be a non-volatile memory suchas Flash memory. In one embodiment, a non-volatile memory may be usedfor persistent storage and a volatile memory may be used for executionof the program code and data at runtime. Moreover, the memory 210 may beintegrated within the low power microcontroller 200 or may be coupled tothe low power microcontroller 200 via a bus or communication fabric. Theunderlying principles of the invention are not limited to any particularimplementation of the memory 210.

As illustrated, the program code may include application program code203 defining an application-specific set of functions to be performed bythe IoT device 201 and library code 202 comprising a set of predefinedbuilding blocks which may be utilized by the application developer ofthe IoT device 101. In one embodiment, the library code 202 comprises aset of basic functions required to implement an IoT device such as acommunication protocol stack 201 for enabling communication between eachIoT device 101 and the IoT hub 110. As mentioned, in one embodiment, thecommunication protocol stack 201 comprises a Bluetooth LE protocolstack. In this embodiment, Bluetooth LE radio and antenna 207 may beintegrated within the low power microcontroller 200. However, theunderlying principles of the invention are not limited to any particularcommunication protocol.

The particular embodiment shown in FIG. 2 also includes a plurality ofinput devices or sensors 210 to receive user input and provide the userinput to the low power microcontroller, which processes the user inputin accordance with the application code 203 and library code 202. In oneembodiment, each of the input devices include an LED 209 to providefeedback to the end user.

In addition, the illustrated embodiment includes a battery 208 forsupplying power to the low power microcontroller. In one embodiment, anon-chargeable coin cell battery is used. However, in an alternateembodiment, an integrated rechargeable battery may be used (e.g.,rechargeable by connecting the IoT device to an AC power supply (notshown)).

A speaker 205 is also provided for generating audio. In one embodiment,the low power microcontroller 299 includes audio decoding logic fordecoding a compressed audio stream (e.g., such as an MPEG-4/AdvancedAudio Coding (AAC) stream) to generate audio on the speaker 205.Alternatively, the low power microcontroller 200 and/or the applicationcode/data 203 may include digitally sampled snippets of audio to provideverbal feedback to the end user as the user enters selections via theinput devices 210.

In one embodiment, one or more other/alternate I/O devices or sensors250 may be included on the IoT device 101 based on the particularapplication for which the IoT device 101 is designed. For example, anenvironmental sensor may be included to measure temperature, pressure,humidity, etc. A security sensor and/or door lock opener may be includedif the IoT device is used as a security device. Of course, theseexamples are provided merely for the purposes of illustration. Theunderlying principles of the invention are not limited to any particulartype of IoT device. In fact, given the highly programmable nature of thelow power microcontroller 200 equipped with the library code 202, anapplication developer may readily develop new application code 203 andnew I/O devices 250 to interface with the low power microcontroller forvirtually any type of IoT application.

In one embodiment, the low power microcontroller 200 also includes asecure key store for storing encryption keys used by the embodimentsdescribed below (see, e.g., FIGS. 4-6 and associated text).Alternatively, the keys may be secured in a subscriber identify module(SIM) as discussed below.

A wakeup receiver 207 is included in one embodiment to wake the IoTdevice from an ultra low power state in which it is consuming virtuallyno power. In one embodiment, the wakeup receiver 207 is configured tocause the IoT device 101 to exit this low power state in response to awakeup signal received from a wakeup transmitter 307 configured on theIoT hub 110 as shown in FIG. 3. In particular, in one embodiment, thetransmitter 307 and receiver 207 together form an electrical resonanttransformer circuit such as a Tesla coil. In operation, energy istransmitted via radio frequency signals from the transmitter 307 to thereceiver 207 when the hub 110 needs to wake the IoT device 101 from avery low power state. Because of the energy transfer, the IoT device 101may be configured to consume virtually no power when it is in its lowpower state because it does not need to continually “listen” for asignal from the hub (as is the case with network protocols which allowdevices to be awakened via a network signal). Rather, themicrocontroller 200 of the IoT device 101 may be configured to wake upafter being effectively powered down by using the energy electricallytransmitted from the transmitter 307 to the receiver 207.

As illustrated in FIG. 3, the IoT hub 110 also includes a memory 317 forstoring program code and data 305 and hardware logic 301 such as amicrocontroller for executing the program code and processing the data.A wide area network (WAN) interface 302 and antenna 310 couple the IoThub 110 to the cellular service 115. Alternatively, as mentioned above,the IoT hub 110 may also include a local network interface (not shown)such as a WiFi interface (and WiFi antenna) or Ethernet interface forestablishing a local area network communication channel. In oneembodiment, the hardware logic 301 also includes a secure key store forstoring encryption keys used by the embodiments described below (see,e.g., FIGS. 4-6 and associated text). Alternatively, the keys may besecured in a subscriber identify module (SIM) as discussed below.

A local communication interface 303 and antenna 311 establishes localcommunication channels with each of the IoT devices 101-105. Asmentioned above, in one embodiment, the local communication interface303/antenna 311 implements the Bluetooth LE standard. However, theunderlying principles of the invention are not limited to any particularprotocols for establishing the local communication channels with the IoTdevices 101-105. Although illustrated as separate units in FIG. 3, theWAN interface 302 and/or local communication interface 303 may beembedded within the same chip as the hardware logic 301.

In one embodiment, the program code and data includes a communicationprotocol stack 308 which may include separate stacks for communicatingover the local communication interface 303 and the WAN interface 302. Inaddition, device pairing program code and data 306 may be stored in thememory to allow the IoT hub to pair with new IoT devices. In oneembodiment, each new IoT device 101-105 is assigned a unique code whichis communicated to the IoT hub 110 during the pairing process. Forexample, the unique code may be embedded in a barcode on the IoT deviceand may be read by the barcode reader 106 or may be communicated overthe local communication channel 130. In an alternate embodiment, theunique ID code is embedded magnetically on the IoT device and the IoThub has a magnetic sensor such as an radio frequency ID (RFID) or nearfield communication (NFC) sensor to detect the code when the IoT device101 is moved within a few inches of the IoT hub 110.

In one embodiment, once the unique ID has been communicated, the IoT hub110 may verify the unique ID by querying a local database (not shown),performing a hash to verify that the code is acceptable, and/orcommunicating with the IoT service 120, user device 135 and/or Website130 to validate the ID code. Once validated, in one embodiment, the IoThub 110 pairs the IoT device 101 and stores the pairing data in memory317 (which, as mentioned, may include non-volatile memory). Once pairingis complete, the IoT hub 110 may connect with the IoT device 101 toperform the various IoT functions described herein.

In one embodiment, the organization running the IoT service 120 mayprovide the IoT hub 110 and a basic hardware/software platform to allowdevelopers to easily design new IoT services. In particular, in additionto the IoT hub 110, developers may be provided with a softwaredevelopment kit (SDK) to update the program code and data 305 executedwithin the hub 110. In addition, for IoT devices 101, the SDK mayinclude an extensive set of library code 202 designed for the base IoThardware (e.g., the low power microcontroller 200 and other componentsshown in FIG. 2) to facilitate the design of various different types ofapplications 101. In one embodiment, the SDK includes a graphical designinterface in which the developer needs only to specify input and outputsfor the IoT device. All of the networking code, including thecommunication stack 201 that allows the IoT device 101 to connect to thehub 110 and the service 120, is already in place for the developer. Inaddition, in one embodiment, the SDK also includes a library code baseto facilitate the design of apps for mobile devices (e.g., iPhone andAndroid devices).

In one embodiment, the IoT hub 110 manages a continuous bi-directionalstream of data between the IoT devices 101-105 and the IoT service 120.In circumstances where updates to/from the IoT devices 101-105 arerequired in real time (e.g., where a user needs to view the currentstatus of security devices or environmental readings), the IoT hub maymaintain an open TCP socket to provide regular updates to the userdevice 135 and/or external Websites 130. The specific networkingprotocol used to provide updates may be tweaked based on the needs ofthe underlying application. For example, in some cases, where may notmake sense to have a continuous bi-directional stream, a simplerequest/response protocol may be used to gather information when needed.

In one embodiment, both the IoT hub 110 and the IoT devices 101-105 areautomatically upgradeable over the network. In particular, when a newupdate is available for the IoT hub 110 it may automatically downloadand install the update from the IoT service 120. It may first copy theupdated code into a local memory, run and verify the update beforeswapping out the older program code. Similarly, when updates areavailable for each of the IoT devices 101-105, they may initially bedownloaded by the IoT hub 110 and pushed out to each of the IoT devices101-105. Each IoT device 101-105 may then apply the update in a similarmanner as described above for the IoT hub and report back the results ofthe update to the IoT hub 110. If the update is successful, then the IoThub 110 may delete the update from its memory and record the latestversion of code installed on each IoT device (e.g., so that it maycontinue to check for new updates for each IoT device).

In one embodiment, the IoT hub 110 is powered via A/C power. Inparticular, the IoT hub 110 may include a power unit 390 with atransformer for transforming A/C voltage supplied via an A/C power cordto a lower DC voltage.

FIG. 4 illustrates a high level architecture which uses public keyinfrastructure (PKI) techniques and/or symmetric key exchange/encryptiontechniques to encrypt communications between the IoT Service 120, theIoT hub 110 and the IoT devices 101-102.

Embodiments which use public/private key pairs will first be described,followed by embodiments which use symmetric key exchange/encryptiontechniques. In particular, in an embodiment which uses PKI, a uniquepublic/private key pair is associated with each IoT device 101-102, eachIoT hub 110 and the IoT service 120. In one embodiment, when a new IoThub 110 is set up, its public key is provided to the IoT service 120 andwhen a new IoT device 101 is set up, it's public key is provided to boththe IoT hub 110 and the IoT service 120. Various techniques for securelyexchanging the public keys between devices are described below. In oneembodiment, all public keys are signed by a master key known to all ofthe receiving devices (i.e., a form of certificate) so that anyreceiving device can verify the validity of the public keys byvalidating the signatures. Thus, these certificates would be exchangedrather than merely exchanging the raw public keys.

As illustrated, in one embodiment, each IoT device 101, 102 includes asecure key storage 401, 403, respectively, for security storing eachdevice's private key. Security logic 402, 404 then utilizes the securelystored private keys to perform the encryption/decryption operationsdescribed herein. Similarly, the IoT hub 110 includes a secure storage411 for storing the IoT hub private key and the public keys of the IoTdevices 101-102 and the IoT service 120; as well as security logic 412for using the keys to perform encryption/decryption operations. Finally,the IoT service 120 may include a secure storage 421 for securitystoring its own private key, the public keys of various IoT devices andIoT hubs, and a security logic 413 for using the keys to encrypt/decryptcommunication with IoT hubs and devices. In one embodiment, when the IoThub 110 receives a public key certificate from an IoT device it canverify it (e.g., by validating the signature using the master key asdescribed above), and then extract the public key from within it andstore that public key in it's secure key store 411.

By way of example, in one embodiment, when the IoT service 120 needs totransmit a command or data to an IoT device 101 (e.g., a command tounlock a door, a request to read a sensor, data to beprocessed/displayed by the IoT device, etc) the security logic 413encrypts the data/command using the public key of the IoT device 101 togenerate an encrypted IoT device packet. In one embodiment, it thenencrypts the IoT device packet using the public key of the IoT hub 110to generate an IoT hub packet and transmits the IoT hub packet to theIoT hub 110. In one embodiment, the service 120 signs the encryptedmessage with it's private key or the master key mentioned above so thatthe device 101 can verify it is receiving an unaltered message from atrusted source. The device 101 may then validate the signature using thepublic key corresponding to the private key and/or the master key. Asmentioned above, symmetric key exchange/encryption techniques may beused instead of public/private key encryption. In these embodiments,rather than privately storing one key and providing a correspondingpublic key to other devices, the devices may each be provided with acopy of the same symmetric key to be used for encryption and to validatesignatures. One example of a symmetric key algorithm is the AdvancedEncryption Standard (AES), although the underlying principles of theinvention are not limited to any type of specific symmetric keys.

Using a symmetric key implementation, each device 101 enters into asecure key exchange protocol to exchange a symmetric key with the IoThub 110. A secure key provisioning protocol such as the DynamicSymmetric Key Provisioning Protocol (DSKPP) may be used to exchange thekeys over a secure communication channel (see, e.g., Request forComments (RFC) 6063). However, the underlying principles of theinvention are not limited to any particular key provisioning protocol.

Once the symmetric keys have been exchanged, they may be used by eachdevice 101 and the IoT hub 110 to encrypt communications. Similarly, theIoT hub 110 and IoT service 120 may perform a secure symmetric keyexchange and then use the exchanged symmetric keys to encryptcommunications. In one embodiment a new symmetric key is exchangedperiodically between the devices 101 and the hub 110 and between the hub110 and the IoT service 120. In one embodiment, a new symmetric key isexchanged with each new communication session between the devices 101,the hub 110, and the service 120 (e.g., a new key is generated andsecurely exchanged for each communication session). In one embodiment,if the security module 412 in the IoT hub is trusted, the service 120could negotiate a session key with the hub security module 412 and thenthe security module 412 would negotiate a session key with each device120. Messages from the service 120 would then be decrypted and verifiedin the hub security module 412 before being re-encrypted fortransmission to the device 101.

In one embodiment, to prevent a compromise on the hub security module412 a one-time (permanent) installation key may be negotiated betweenthe device 101 and service 120 at installation time. When sending amessage to a device 101 the service 120 could first encrypt/MAC withthis device installation key, then encrypt/MAC that with the hub'ssession key. The hub 110 would then verify and extract the encrypteddevice blob and send that to the device.

In one embodiment of the invention, a counter mechanism is implementedto prevent replay attacks. For example, each successive communicationfrom the device 101 to the hub 110 (or vice versa) may be assigned acontinually increasing counter value. Both the hub 110 and device 101will track this value and verify that the value is correct in eachsuccessive communication between the devices. The same techniques may beimplemented between the hub 110 and the service 120. Using a counter inthis manner would make it more difficult to spoof the communicationbetween each of the devices (because the counter value would beincorrect). However, even without this a shared installation key betweenthe service and device would prevent network (hub) wide attacks to alldevices.

In one embodiment, when using public/private key encryption, the IoT hub110 uses its private key to decrypt the IoT hub packet and generate theencrypted IoT device packet, which it transmits to the associated IoTdevice 101. The IoT device 101 then uses its private key to decrypt theIoT device packet to generate the command/data originated from the IoTservice 120. It may then process the data and/or execute the command.Using symmetric encryption, each device would encrypt and decrypt withthe shared symmetric key. If either case, each transmitting device mayalso sign the message with it's private key so that the receiving devicecan verify it's authenticity.

A different set of keys may be used to encrypt communication from theIoT device 101 to the IoT hub 110 and to the IoT service 120. Forexample, using a public/private key arrangement, in one embodiment, thesecurity logic 402 on the IoT device 101 uses the public key of the IoThub 110 to encrypt data packets sent to the IoT hub 110. The securitylogic 412 on the IoT hub 110 may then decrypt the data packets using theIoT hub's private key. Similarly, the security logic 402 on the IoTdevice 101 and/or the security logic 412 on the IoT hub 110 may encryptdata packets sent to the IoT service 120 using the public key of the IoTservice 120 (which may then be decrypted by the security logic 413 onthe IoT service 120 using the service's private key). Using symmetrickeys, the device 101 and hub 110 may share a symmetric key while the huband service 120 may share a different symmetric key.

While certain specific details are set forth above in the descriptionabove, it should be noted that the underlying principles of theinvention may be implemented using various different encryptiontechniques. For example, while some embodiments discussed above useasymmetric public/private key pairs, an alternate embodiment may usesymmetric keys securely exchanged between the various IoT devices101-102, IoT hubs 110, and the IoT service 120. Moreover, in someembodiments, the data/command itself is not encrypted, but a key is usedto generate a signature over the data/command (or other data structure).The recipient may then use its key to validate the signature.

As illustrated in FIG. 5, in one embodiment, the secure key storage oneach IoT device 101 is implemented using a programmable subscriberidentity module (SIM) 501. In this embodiment, the IoT device 101 mayinitially be provided to the end user with an un-programmed SIM card 501seated within a SIM interface 500 on the IoT device 101. In order toprogram the SIM with a set of one or more encryption keys, the usertakes the programmable SIM card 501 out of the SIM interface 500 andinserts it into a SIM programming interface 502 on the IoT hub 110.Programming logic 525 on the IoT hub then securely programs the SIM card501 to register/pair the IoT device 101 with the IoT hub 110 and IoTservice 120. In one embodiment, a public/private key pair may berandomly generated by the programming logic 525 and the public key ofthe pair may then be stored in the IoT hub's secure storage device 411while the private key may be stored within the programmable SIM 501. Inaddition, the programming logic 525 may store the public keys of the IoThub 110, the IoT service 120, and/or any other IoT devices 101 on theSIM card 501 (to be used by the security logic 402 on the IoT device 101to encrypt outgoing data). Once the SIM 501 is programmed, the new IoTdevice 101 may be provisioned with the IoT Service 120 using the SIM asa secure identifier (e.g., using existing techniques for registering adevice using a SIM). Following provisioning, both the IoT hub 110 andthe IoT service 120 will securely store a copy of the IoT device'spublic key to be used when encrypting communication with the IoT device101.

The techniques described above with respect to FIG. 5 provide enormousflexibility when providing new IoT devices to end users. Rather thanrequiring a user to directly register each SIM with a particular serviceprovider upon sale/purchase (as is currently done), the SIM may beprogrammed directly by the end user via the IoT hub 110 and the resultsof the programming may be securely communicated to the IoT service 120.Consequently, new IoT devices 101 may be sold to end users from onlineor local retailers and later securely provisioned with the IoT service120.

While the registration and encryption techniques are described abovewithin the specific context of a SIM (Subscriber Identity Module), theunderlying principles of the invention are not limited to a “SIM”device. Rather, the underlying principles of the invention may beimplemented using any type of device having secure storage for storing aset of encryption keys. Moreover, while the embodiments above include aremovable SIM device, in one embodiment, the SIM device is not removablebut the IoT device itself may be inserted within the programminginterface 502 of the IoT hub 110.

In one embodiment, rather than requiring the user to program the SIM (orother device), the SIM is pre-programmed into the IoT device 101, priorto distribution to the end user. In this embodiment, when the user setsup the IoT device 101, various techniques described herein may be usedto securely exchange encryption keys between the IoT hub 110/IoT service120 and the new IoT device 101.

For example, as illustrated in FIG. 6A each IoT device 101 or SIM 401may be packaged with a barcode or QR code 601 uniquely identifying theIoT device 101 and/or SIM 401. In one embodiment, the barcode or QR code601 comprises an encoded representation of the public key for the IoTdevice 101 or SIM 401. Alternatively, the barcode or QR code 601 may beused by the IoT hub 110 and/or IoT service 120 to identify or generatethe public key (e.g., used as a pointer to the public key which isalready stored in secure storage). The barcode or QR code 601 may beprinted on a separate card (as shown in FIG. 6A) or may be printeddirectly on the IoT device itself. Regardless of where the barcode isprinted, in one embodiment, the IoT hub 110 is equipped with a barcodereader 206 for reading the barcode and providing the resulting data tothe security logic 412 on the IoT hub 110 and/or the security logic 413on the IoT service 120. The security logic 412 on the IoT hub 110 maythen store the public key for the IoT device within its secure keystorage 411 and the security logic 413 on the IoT service 120 may storethe public key within its secure storage 421 (to be used for subsequentencrypted communication).

In one embodiment, the data contained in the barcode or QR code 601 mayalso be captured via a user device 135 (e.g., such as an iPhone orAndroid device) with an installed IoT app or browser-based appletdesigned by the IoT service provider. Once captured, the barcode datamay be securely communicated to the IoT service 120 over a secureconnection (e.g., such as a secure sockets layer (SSL) connection). Thebarcode data may also be provided from the client device 135 to the IoThub 110 over a secure local connection (e.g., over a local WiFi orBluetooth LE connection).

The security logic 402 on the IoT device 101 and the security logic 412on the IoT hub 110 may be implemented using hardware, software, firmwareor any combination thereof. For example, in one embodiment, the securitylogic 402, 412 is implemented within the chips used for establishing thelocal communication channel 130 between the IoT device 101 and the IoThub 110 (e.g., the Bluetooth LE chip if the local channel 130 isBluetooth LE). Regardless of the specific location of the security logic402, 412, in one embodiment, the security logic 402, 412 is designed toestablish a secure execution environment for executing certain types ofprogram code. This may be implemented, for example, by using TrustZonetechnology (available on some ARM processors) and/or Trusted ExecutionTechnology (designed by Intel). Of course, the underlying principles ofthe invention are not limited to any particular type of secure executiontechnology.

In one embodiment, the barcode or QR code 601 may be used to pair eachIoT device 101 with the IoT hub 110. For example, rather than using thestandard wireless pairing process currently used to pair Bluetooth LEdevices, a pairing code embedded within the barcode or QR code 601 maybe provided to the IoT hub 110 to pair the IoT hub with thecorresponding IoT device.

FIG. 6B illustrates one embodiment in which the barcode reader 206 onthe IoT hub 110 captures the barcode/QR code 601 associated with the IoTdevice 101. As mentioned, the barcode/QR code 601 may be printeddirectly on the IoT device 101 or may be printed on a separate cardprovided with the IoT device 101. In either case, the barcode reader 206reads the pairing code from the barcode/QR code 601 and provides thepairing code to the local communication module 680. In one embodiment,the local communication module 680 is a Bluetooth LE chip and associatedsoftware, although the underlying principles of the invention are notlimited to any particular protocol standard. Once the pairing code isreceived, it is stored in a secure storage containing pairing data 685and the IoT device 101 and IoT hub 110 are automatically paired. Eachtime the IoT hub is paired with a new IoT device in this manner, thepairing data for that pairing is stored within the secure storage 685.In one embodiment, once the local communication module 680 of the IoThub 110 receives the pairing code, it may use the code as a key toencrypt communications over the local wireless channel with the IoTdevice 101.

Similarly, on the IoT device 101 side, the local communication module690 stores pairing data within a local secure storage device 695indicating the pairing with the IoT hub. The pairing data 695 mayinclude the pre-programmed pairing code identified in the barcode/QRcode 601. The pairing data 695 may also include pairing data receivedfrom the local communication module 680 on the IoT hub 110 required forestablishing a secure local communication channel (e.g., an additionalkey to encrypt communication with the IoT hub 110).

Thus, the barcode/QR code 601 may be used to perform local pairing in afar more secure manner than current wireless pairing protocols becausethe pairing code is not transmitted over the air. In addition, in oneembodiment, the same barcode/QR code 601 used for pairing may be used toidentify encryption keys to build a secure connection from the IoTdevice 101 to the IoT hub 110 and from the IoT hub 110 to the IoTservice 120.

A method for programming a SIM card in accordance with one embodiment ofthe invention is illustrated in FIG. 7. The method may be implementedwithin the system architecture described above, but is not limited toany particular system architecture.

At 701, a user receives a new IoT device with a blank SIM card and, at702, the user inserts the blank SIM card into an IoT hub. At 703, theuser programs the blank SIM card with a set of one or more encryptionkeys. For example, as mentioned above, in one embodiment, the IoT hubmay randomly generate a public/private key pair and store the privatekey on the SIM card and the public key in its local secure storage. Inaddition, at 704, at least the public key is transmitted to the IoTservice so that it may be used to identify the IoT device and establishencrypted communication with the IoT device. As mentioned above, in oneembodiment, a programmable device other than a “SIM” card may be used toperform the same functions as the SIM card in the method shown in FIG.7.

A method for integrating a new IoT device into a network is illustratedin FIG. 8. The method may be implemented within the system architecturedescribed above, but is not limited to any particular systemarchitecture.

At 801, a user receives a new IoT device to which an encryption key hasbeen pre-assigned. At 802, the key is securely provided to the IoT hub.As mentioned above, in one embodiment, this involves reading a barcodeassociated with the IoT device to identify the public key of apublic/private key pair assigned to the device. The barcode may be readdirectly by the IoT hub or captured via a mobile device via an app orbrowser. In an alternate embodiment, a secure communication channel suchas a Bluetooth LE channel, a near field communication (NFC) channel or asecure WiFi channel may be established between the IoT device and theIoT hub to exchange the key. Regardless of how the key is transmitted,once received, it is stored in the secure keystore of the IoT hubdevice. As mentioned above, various secure execution technologies may beused on the IoT hub to store and protect the key such as SecureEnclaves, Trusted Execution Technology (TXT), and/or Trustzone. Inaddition, at 803, the key is securely transmitted to the IoT servicewhich stores the key in its own secure keystore. It may then use the keyto encrypt communication with the IoT device. One again, the exchangemay be implemented using a certificate/signed key. Within the hub 110 itis particularly important to prevent modification/addition/removal ofthe stored keys.

A method for securely communicating commands/data to an IoT device usingpublic/private keys is illustrated in FIG. 9. The method may beimplemented within the system architecture described above, but is notlimited to any particular system architecture.

At 901, the IoT service encrypts the data/commands using the IoT devicepublic key to create an IoT device packet. It then encrypts the IoTdevice packet using IoT hub's public key to create the IoT hub packet(e.g., creating an IoT hub wrapper around the IoT device packet). At902, the IoT service transmits the IoT hub packet to the IoT hub. At903, the IoT hub decrypts the IoT hub packet using the IoT hub's privatekey to generate the IoT device packet. At 904 it then transmits the IoTdevice packet to the IoT device which, at 905, decrypts the IoT devicepacket using the IoT device private key to generate the data/commands.At 906, the IoT device processes the data/commands.

In an embodiment which uses symmetric keys, a symmetric key exchange maybe negotiated between each of the devices (e.g., each device and the huband between the hub and the service). Once the key exchange is complete,each transmitting device encrypts and/or signs each transmission usingthe symmetric key before transmitting data to the receiving device.

Embodiments of the invention may include various steps, which have beendescribed above. The steps may be embodied in machine-executableinstructions which may be used to cause a general-purpose orspecial-purpose processor to perform the steps. Alternatively, thesesteps may be performed by specific hardware components that containhardwired logic for performing the steps, or by any combination ofprogrammed computer components and custom hardware components.

As described herein, instructions may refer to specific configurationsof hardware such as application specific integrated circuits (ASICs)configured to perform certain operations or having a predeterminedfunctionality or software instructions stored in memory embodied in anon-transitory computer readable medium. Thus, the techniques shown inthe figures can be implemented using code and data stored and executedon one or more electronic devices (e.g., an end station, a networkelement, etc.). Such electronic devices store and communicate(internally and/or with other electronic devices over a network) codeand data using computer machine-readable media, such as non-transitorycomputer machine-readable storage media (e.g., magnetic disks; opticaldisks; random access memory; read only memory; flash memory devices;phase-change memory) and transitory computer machine-readablecommunication media (e.g., electrical, optical, acoustical or other formof propagated signals—such as carrier waves, infrared signals, digitalsignals, etc.). In addition, such electronic devices typically include aset of one or more processors coupled to one or more other components,such as one or more storage devices (non-transitory machine-readablestorage media), user input/output devices (e.g., a keyboard, atouchscreen, and/or a display), and network connections. The coupling ofthe set of processors and other components is typically through one ormore busses and bridges (also termed as bus controllers). The storagedevice and signals carrying the network traffic respectively representone or more machine-readable storage media and machine-readablecommunication media. Thus, the storage device of a given electronicdevice typically stores code and/or data for execution on the set of oneor more processors of that electronic device. Of course, one or moreparts of an embodiment of the invention may be implemented usingdifferent combinations of software, firmware, and/or hardware.

Throughout this detailed description, for the purposes of explanation,numerous specific details were set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however, toone skilled in the art that the invention may be practiced without someof these specific details. In certain instances, well known structuresand functions were not described in elaborate detail in order to avoidobscuring the subject matter of the present invention. Accordingly, thescope and spirit of the invention should be judged in terms of theclaims which follow.

What is claimed is:
 1. A system comprising: an Internet of Things (IoT)hub comprising a network interface to couple the IoT hub to an IoTservice over a wide area network (WAN), and programming logic to programan identification device with one or more encryption keys usable toestablish encrypted communication with an IoT device; and at least oneIoT device interfacing with the identification device followingprogramming of the identification device by the IoT hub; wherein oncethe identification device is programmed and interfaced with the IoTdevice, the IoT device uses the one or more keys to establish a securecommunication channel with the IoT hub and/or the IoT service.